Projet 19 - "Documenter une méthode pour synchroniser un monorepo vers des multirepos qui fonctionne dans les deux sens"

Date de la création de cette note : 6 décembre 2024.

Quel est l'objectif de ce projet ?

En décembre 2017, convaincu par les avantages du modèle Monorepo, j'ai effectué un véritable changement de paradigme en abandonnant le modèle Multirepos.

Depuis, je n'ai eu aucun regret. J'utilise le modèle Monorepo dans tous mes projets, car il simplifie énormément la plutpart des workflow, notamment l'onboarding, grâce à des kits de développement simplifiés.

Cependant, le modèle Multirepos est très populaire, je le rencontre partout où j'interviens.
Cela me perturbe beaucoup, car je constate à chaque fois que ce modèle complique tout. L'onboarding, le flux de travail, de déploiement, la documentation…

L'objectif de ce projet est de documenter une méthode et des outils qui me permettent de maintenir en douceur, sans rien imposer, un monorepo qui contient un development kit de qualité, agréable à utiliser.

Je souhaite pouvoir travailler dans ce monorepo tout en envoyant mon travail dans des branches sur les multi repositories d'origine.

Je souhaite aussi pouvoir pull les changements des multi repositories vers mon monorepo.

Ces deux user stories me permettront d'améliorer le monorepo sans modifier le workflow de développement des autres membres de l'équipe.

Une fois le kit de développement du monorepo opérationnel, je pourrai présenter ce projet à l'équipe pour leur en montrer le fonctionnement, les avantages, ainsi que sa simplicité d'utilisation et d'onboarding.

Au final, il reviendra à l'équipe de décider si elle souhaite adopter ce paradigme ou non.

Repository de ce projet :

https://github.com/stephane-klein/poc-git-monorepo-multirepos-sync

Ressources :

Journaux liées à cette note :

Je pense être arrivé à une solution plus ou moins satisfaisante pour le Projet 19 - "Documenter une méthode pour synchroniser un monorepo vers des multirepos qui fonctionne dans les deux sens".

Voici-ci, ci-dessous, les étapes de la démonstration qui sont détaillées dans le README.md du repository poc-git-monorepo-multirepos-sync.

Je crée deux repositories : frontend et backend (multi repositories) ;
J'utilise le script tomono pour les intégrer dans un monorepo nommé monorepo ;
J'ajoute deux fichiers à la racine de monorepo : README.md et .mise.toml ;
J'effectue des changements dans le repository frontend, je commit ;
Je pull les changements du repository frontend vers monorepo ;
Dans monorepo, j'effectue des changements dans le dossier frontend/, je commit ;
J'utilise cd frontend/; git format-patch --relative -1 HEAD pour générer un patch qui contient les changements que j'ai effectués dans le dossier frontend/ ;
Je vais dans le repository frontend et j'applique les changements contenus dans ce patch avec la command git apply monpatch.patch ou avec git am monptach.patch.

Pour le moment, j'ai privilégié l'option git patch, parce que je souhaite suivre la méthode la plus "manuelle" que j'ai pu trouver lorsque je dois intervenir sur les repositories upstream, parce que je ne veux prendre aucun risque de perturber mes collègues avec mon initiative de monorepo.

Le repository GitHub suivant contient le résultat final du monorepo : https://github.com/stephane-klein/poc-git-monorepo-multirepos-sync-result-example/.

Est-ce que je suis satisfait du résultat de cette démo ?

La réponse est oui, bien que je ne sois pas satisfait de quelques éléments.
Par exemple, les fichiers de frontend présents dans ce commit ne sont pas dans le dossier frontend. J'aimerais que ces titres de commits contiennent un prefix [frontend] ... et [backend].... Je pense que cela doit être possible à implémenter en modifiant le script tomono.

Est-ce que c'est pénible à utiliser ? Pour le moment, ma réponse est « je ne sais pas ».

Je vais tester cette méthode avec deux projets. Je pense écrire une note de bilan de cette expérience d'ici à quelques semaines.

En travaillant sur Projet 19, #JaiDécouvert le projet git-branchless (https://github.com/arxanas/git-branchless).

High-velocity, monorepo-scale workflow for Git.

Je n'ai pas encore compris à quoi cela sert.

Je viens de rédiger Projet 19 - "Documenter une méthode pour synchroniser un monorepo vers des multirepos qui fonctionne dans les deux sens".